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OPMilOG iAIfr SIMPLE PICTURE ^RCKil^HS- 


J. IMjTWHHJCTtOM 

This jjviipb/■ reports on progress in the development of a monitor for 
debugging elementary programs . Such research ia important both If or Its 
Ejrt.ut.iira; applications as «li as for its icnrestigaticB of concepts 
*r. iuh dr re Fundfttaflflfctl to E5-ro Sj r«BMn .Ln ^ Skill, A MHputer n»nitOI called 
fl VCRtiF•' ;W:, ■•.•&wi» designed Shat can repair simple prugrams far dr-tnifi^ 
pit fcures I Golds tain 1974], The reasonw to dmJ&p suth monitors ar«: 

• . Vo provide a nora precise under standing of the nature Of 
programaing slr.niai 

2, v’> facilitate the development of math lues s#f«y.d of 
debijidflj.n® and espUEidiJig upon the programs given them by 
humans; and 

a. to ijrtdude insight into Else p;-ohiaiu solving process so 
AV-." it can. be described store cmstructively to tittidferi Ls . 

PtY: rc.: ; V i:; intended to supply otcaslemei advice to i student to aid 

in the debugging of idrogrttas that go awry, (dual as tb* system’s 

ratitsar.^ : aycroft Holmes., occasionally supplied advice to his younger 

brotdfti SJisrXooJt on particularly difficult cases, j In this interaction, 

tha i'sas- Biippll&s statements that describe eats acts of the in tended 

pic.tu.ri uoJ ;o' : it. %nd the system fills in details of this commentary:. 

iliegnya.’iL- Ims-js, uW suuaasts corrections. In tills paper, fto&evor. I 

shall r+ot empi3esi.ee this Interactive role Instead, my primary purpose 

*i.\2, bo to describe JtYCWT as a model of the debugging process This 

A* regionr.fc \a aluct: WVCRwhT's utility as an advisor stems directly from 

its Ut'id'^ri landing of debugging still, 

rtYCftUK'f is; abl’S to correct the programs. responsible for the bugged 

pictures lit figures 1,1, 1,3, 1.4 dud L5 so that thu intended 

Pldfc i j - as &r$ ach levad . In this paper* ■ ftji a debugg ing of figure 1.1, a. 




typical example, will fie thoroughly explained. Figures 1,3, 1,4 and 1,5 
are corrected irt analogous ways: see ^Goldstein 19""?4 J for details- 




Plcture drawn by NAPOLEON 


FIGURE 1,1 


FIGURE \.Z 



INTENDED TREE 


FIGURE U 


Picture drawn by 
bugged TREE program 
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Picture drawn by bugged WI5K1K6WE1L 
program 


Intended WISHINGWELL 

FIGURE 1.4 




FACEHAfl 


Picture drawn by bugged 

FACEMAN program 


FIGURE 1.5 

















These pictures are drawn by program BaiUpulatlun of a graphics 
device called the turtle which has a pen that can leav^ a tract alonn 
the turtle's path. Turtles slay an important role in the LOGO 
environment where children learn problem solving and mathematics by 
programming display turtles, physical turtles with various sensors,, and 
music boxes ^Papert !D71 h 107-Zj. Turtle programs have proven tQ bd an 
cxcell&nt starting point for t-eaching programing to children of all 
ages, and. therefore provide a reasonable initial problem donain for 
building a program understanding system. 

The context Of hYCROFT'S activity is the interaction of three kinds 
of description: graphical (i,a, the picture actually drawnj, procedural 
(the turtle program used to generate the picture) and predicative [the 
collection Of statements used to describe the desired scene). For 
HYCROFT, debugging is making the procedural description produce a 
graphical result that satisfies the set of predicates describing intent. 
Thus, debugging here is a process that mediates between different 
representations of the some object, 

l_. l FLOWCHART OF THE SYSTEM 

The organization of the monitor system is illustrated in figure 1,6, 
Input to SYCROFT consists uf the user's prograns and a, model of the 
intended outcome. For the graphics world, the model is a conjunction of 
geometric predicates describing important properties of the intended 
picture, MYCROFT then analyzes the program, building both a Cartesian 
annotation of the picture that is actually drawn and a plan explaining 
the relationship batWeeh the program and model, [Any or all of the plan 
can be supplied directly by the 'user, thereby simplifying HYCfioFT’s 


task,) 


FIGURE 1. 



FLOWCHART OF MYCROFT 




























The next step is for the system to interpret the urogram's 
performance in terms of the nodal and produce a description of the 


discrepancies. These discrepancies era 
violated model statements. The task is 
each violation. The final output is an 
Copious commontary) which Satisfies the 


expressed as a list of the 
then for the debugger to repair 
edited turtle program (with 
model r (Occasionally, the plan 


that HVCROFT hypothesises requires implausible repairs-for example. 


major deletions of user code-'resulting in the debugger asking the plan 


finder for a new plan.) 

The remainder of this first section describes the debugging of 
NAPOLEON (figure 1.1) and introduces some important Ideas about the 
nature Of plans , Section 2 describes the annotator used to document Lh 
performance of turtle programs. Section S introduces the plan-finder 
and section 4 discusses the debugger. Section 3 concludes with 
suggestions for future research. 


1.2 PICTURE HOUELS 

To judge the success of a program, M.YCKOFT requires as input from 
the user a description of intent. A declarative language has been 
designed to define picture models. These models specify important 
properties of the desired final Outcome without indicating the details 
of the drawing process, The primitives of the iwdel language are 
geometric predicates for such properties as Connectivity, relative 
position, length and location. The following models are typical of 
those that the user might provide to describe figure 1,2. 
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HQ DEL HAN 

HI PARTS HEAD BODY ARMS LEGS 
M2 EQUITR1 HEAD 
Hi LINE BODY 
H4 V ARMS r V LEGS 

H5 CONNECTED HEAD BODY , CONNECTED BODY ARMS, CONNECTED BODY LEGS 

tt& BELOW LEGS ARMS, BELOW ARAB HEAD 

END 

MODEL V 

HI PARTS LI U 

HZ LINE LI, LINE ll 

FB CONNECTED LI 12 (VIA ENDPOINTS) 

END 

MODEL EQLITR1 

HI PARTS (SIDE, 3) (ROTATION SJ 
H£ FOR -EACH SIDE (= {LENGTH SIDE) IM ) 

Hi FOR-EACH ROTATION (= (DEGREES ROTATION) 120) 

H4 RING CONNECTED SIDE 
END 

TAc- HAN anti V models ute underdatermined: they do not describe, for 
example* the actual size of tho pictures, The user has latitude ID his 
description of Intent because HYCROFT is designed only to deburj programs 
that Lire almost correct. Therefore, not oply the model, but also the 
picture drawn by the program and! the deTlnitloh of tha procedure provide 
clues to the purpose of the prograil- 


1,3 THE NAPOLEON EXAMPLE 


HYCROFT is destined to repair a simple class of procedures cal Led 
Fixed-Instruction Programs. Those are procedures in which the 
prinitives are restricted to constant inputs, Swb-procodurcs aro 
allowed; however, no conditionals, variables, recursions or iterations 
are permitted. Given heiew are the three programs which drew figure 
1 , I--NAPOLEON, V£E, «ud TRICORN, The "<-■ commentary is called the plan 
and was generated by HYCROFT to link the picture modols--NAN, V and 
EQUITRI--to the programs. 



TO NAPOLEON 

<- 

(accomplish nan) 

ID VEE 


(accomplish legs) 

20 FORWARD 100 

<- 

(accor.pl ish (piece 1 body)) 

30 VEE 

<* 

(insert arms body) 

40 FORWARD 100 

<- 

(accomplish [piece Z body)) 

&Q LEFT 50 

<- 

(setup headiny [for head)) 

GO TRICORN 

<- 

(acca mp1ish h ead) 

END 



TO VEE 

O 

(accomplish v) 

10 RIGHT 45 

<- 

(setup heading for 11) 

ZQ BACK (DP 

<- 

(accomplish 11) 

30 FORWARD 100 

<* 

(retrace 11) 

40 LEFT B0 

<- 

(setup heading for 12) 

50 BACK 100 

<- 

(accomplish 12) 

60 FORWARD 100 


(retrace 1?.) 

END 



TO TRICORN 

<- 

(accomplish equitrl) 

10 FORWARD 50 

4- 

(acconpiish (piece 1 (sidu 1))) 

20 RIGHT n 

4- 

(accomplish (rotation 1)) 

30 FORWARD 100 

C- 

(accomplish (side Z) ) 

40 RIGHT BO 

t- 

(accomplish (rotation 2)) 

50 FORWARD 300 

<- 

(accomplish (side 3)) 

CO RIGHT 90 

c- 

(accomplish (rotation 3)) 

70 FORWARD 50 

<- 

(accomplish (piece ?. (side 1))? 

F.JvD 



The turtle command 

FORWARD 

moves the turtle in the direction 


is currently pointed: RIGHT rotates the turtle clocliwise around Its 
axis. A coupleto description of LOGD can bo found in [Ahelson 1974], 
but is not needed hero. 

A Cartesian representation of the picture is generated by the 
annotator that describes the performance of the turtle proflrurl. Tho 
nlun is used to bind sub-pictures to model parts. This allows M¥CRAFT 
to interpret the program with repect to the model and produce a list OT 
violated model statements. HKCROfT produces the following list of 


discrepancies Tor VAPOLEON: 

l The body is not a line. 

; 'I hr: legs ere not below the arms . 

IThe arms are not below the head. 

I The head is not an equilateral trianrjle. 


I HOT [ LIME BODVn 
(WOT (BELOW LEGS ARMS)) 
( MOT (BELOW ARMS HEAD J 3 
(MOT ( F.QU1 TR I TRICORN)) 


nVCHOI'T IS able to correct these bups and achieve the intended picture 
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id 

using both planning and debugging knowledge. 

I .4 1’LANS 

This section introduces a vocabulary fnr talking about the structure 
of a procedure which is useful for understanding both the design and 
debugging of programs, A mai n-step is defined as the code required to 
achieve a particular sub-goal (.sub-picture), A preparatory-step 
consists of code needed to setup, cleanup ur interface between mairn- 
steps. Thus, frnn this point of view, a program is understood as a 
sequence of main-steps end preparatory-steps, A sirsllar point of view 
is found in [Eussnan 1973J, The plan consists of the purposes Unking 
main- and preparatory-steps to the model; in the turtle world, the 
purpose of main-stops is to accomplish (.draw) parts of the model; and 
the purpose of preparatory-steps is to properly setup or cleanup the 
turtle state between main-steps or, perhaps, to retrace over some 
previous vector, 

A modular main-step is a sequence of contiguous code intended to 
accomplish & particular goal. Ibis is as opposed to an interrupted: 
main-step whose code ts scattered in pieces throughout the program. In 
NAPOLEON, the main-steps for the legs, arms and head are modular; 
however, the code for the body is interrupted by the insertion of the 
code for the urns into its midst. The Utility of making this 
distinction is that modular main-steps can often be debugged in private 
(i,e, by being run independently of the remainder of the procedure) 
while interrupted main-steps eoroonly fail because of unforseen 

/ 

interactions with the interleaved coda associated with other steps of 


the plan, 



has two stages, the First is to break the task into independent sub- 
goals and design scLutioiis (main-steps) for each. The second is thou to 
domhine these main-steps into a single procedure by concatenating thorn 
into some sequence, adding {where necessary? preparatory--steps to 
provide proper interfacing. The Virtue Of this dppi oath IS that It 
divides tho problem into manageable sub-problems. A disadvantage is 
that occasions ny there may be etnas train ts on the design of some main- 
step Which are flOt recognized when that Step is designed independently 
of the remainder of the problem. Another tli saduflilt-fl-y e Is that linear 
design can fall to recognize opportunities fur suh-routinizing a segment 
of code useful for accomplishing more than one nam-step, A Linear plan 
Will be defined as a plan consisting only of modular main-steps and 
preparatory stepsi a non-1 ihdiir pian may include Interrupted main-steps. 

1 .5 LINEAR tt_E&1JGGjNG 

Linearity is a powerful concept for debugging as well as for 
designing programs. MYCROFT pursues the following linear approach to 
correcting turtle programs! the debugger's first goal it to flit each 
main-step independently so that the code satisfies all intended 
properties of the model part being accomplished. Following this, the 
main-steps are treated as inviolate and relations between [riddel parts 
arc riited by debugging preparatory-steps, This is (ldt the only 
debugging technique available to the system, but it is a Valuable one 
because it embodies Important heuristics (,1) concerning the order In 
which Violations should bo repaired and {21) for selecting the repair- 
point {location in the program) at which thi Sdlt for each violation 
should be attempted. 

Following: this linear approach, MYtROFT repairs tho crooked body and 


the open head of NAPOLEON before correcting the BELOW relations. 


Repairing these parts is done on the basis of Knowledge described in. the 
next two sections. Let us assume for the remainder of this section that 
those property repairs have been made -- NAPOLEON appears as in figure 
1.7 -- and concentrate on the da'buflflinsj of the violated relations. 




'X 


NAPOLEON with corrected 


NAPOLEON with statement IS 
as RIGHT 133 
FIGURE 1.3 


FIGURE 1./ 


Treating main-stops as inviolate and fixing relations by modifying 
setup Steps limits the repair or {BELOW LEGS AHMSJ to three possible 
repair-points: (1) before the tegs as atiitonent 5* (.£) before the first 
piece Of the body as Statement 15 and (3J before accomplishing the arms 
as stfl Cement ?5. HYCROFT understands enough about causality to know 
that there is no point in considering edits following the execution, or 
Statement 30 to affect the arms or legs. The exact changes to be made 
arc determined by imperative semantics for the model, primitives. This 
is procedural knowledge that generates, for a given predicate end 
location in the program, some possible edits that would make true the 





violated predicate. MYCRQFT generally considers alternative strategies 
for correcting a given violations it prefers those edits which produce 
the most bfcrtcflclfll side effects* make minimal changes to the user's 
code or most closely satisfy tho abstract form of the plan- 

For EELOUj the imperative semantics direct DEBUG to place the legs 
helow the arms by adding rotations at the setup Stops. Hore drastic 
modifications to the user's code are possible such as the addition of 
position setups which alter the topology of the picture; however, 
MYCft&FT tries to hE gentle tn the turtle program fusing the heuristic 


that the user’s cade is probably Almost correctJ and considers larger 
changes to the program only if the simpler edits do not succeed.. The 
first setup location considered Is the one immediately prior to 
accomplish inti the Arms- Enserting a rotating as statenent 25. however, 
does not correct the violation and is therefore rejected. The next 
possible edit point is as statement 15. Here, the addition Of EIGHT 135 
makes the lasts PAXTLV-BELOW the arms and produces figure 1.8. This edit 
is possible but IS not preferred both because the legs and arms now 
overlap and because the legs are not CDhPLETELY-EElGW the arms. flVCROFT 
is cautious, beih$j primarily a repairman rather thaa a designer* and is 
reluctant to introduce new connections not described in the model. 

Also, given ft choice, RYCROFT prefers the most constrained Meaning of 
the nodel predicate. If the user had intended figure 1.8, then one 
would expect the model description to include additional declarations 
such as (CONNECTED LEGS ARMS) and (PARTLY -BELOW LEGS AR.15). 

Adding RIGHT GO as statement 5 achieves ( CCMF'LETELY-BELOW LEGS ARHSj 


ahd. the NAPOLEON progran now produces the intended picture (figure 1.21. 
This correction bftS beneficial side effects in also establishing the 
proper relationship between the bead and arms, confirming for RYCp-DFT 


that the edit is reus cm able , since 4 particular underlying cause is 
often responsible for many bugs. Thus the result of (DEBUG {BELOV LEGE 
ARMS)) is: 

5 Kl&HT 90 <- (setup heading sueh-that {below legs arms) 

(below arms head)) 

(assume (* (entry heading) 270)) 

The assume comment records the entry state with respect to which the 
edit was made. If the program is run at a future time in & dew 
environment, then debugging is simplified. The cause of a BELOV 
violation will now imediately be seen to be ait incorrect 4SSllfflp11 Oh, 
an<l the corresponding repair is obvious -- insert code to satisfy the 
entry requirements described by the assumption. This illustrates the 
existence of levels of coiaoentary between the model and the program, 
each layer being more specific, but also more closely tied to the 
particular code andl runtime environment of the program. 

Linear debugging: greatly restricts the possibilities that must be 
considered to repair a violation. It is often successful and 
constitutes a powerful first attack on the problem of finding the proper 
erJiti however t it is not infallible. Knn-linear bugs due td unexpected 
interactions between main-steps would not be caught by this technique . 

Figure 1,9 Illustrates a non-linear bug, {INSIDE MOUTH HEAh) is 
Violated but it cannot be repaired by adjusting the interface between 
these two parts (indicated in figure 1,9 by the dotted line CP) since 
the mouth is longer than the dianeter of the head, The imperative 
semantics for rixing INSIDE recognize this. Consequently, NYCSOFT 
resorts to tho non-Linear technique of modifying main-steps to repair a 
relation between parts. The imperative semantics suggest changing the 
size of one of tile parts because this transformation dues not affect the 
shape nf the part and consequently will probably nut introduce new 


o o 



FIGURE 1.9 

violations in properties describing the part. Advice is required from 
the user to know whether shrinking the mouth is to be preferred to 
expanding tho head- Two nore non-linear debugging techniques are 
discussed in the next two sections: ope is based upon knowing the 
abstract form of plans, and the other OSes domain-dependent theorems 
about global offsets. 

1,6 INSERTIONS 

In programming, an interrupt is a break in normal processing For the 
purpose of servicing a surprise. Interrupts represent an important type 
of plan; they are a necessary probleo solving strategy when a process 
must deal with unpredictable events. Typical situations where 
interrupts prove useful Include servicing a dynamic display, and 
arbitrating the conflicting demands of a time sharing system. In the 
real world, biological creatures must use an interrupt style of 
processing to deal with dangers uf their environment such as predators. 

A very simple type of interrupt is one in which the program 
associated with the interrupt is performed for its side effects and is 
state- tran s parent , i.e. the machine is restored to its pre-interrupt 




state before ordinary processing la resumed r As a result, the main 


process never notices the Interruption, in the turtle world, an 
analogous type of organisation is that of an inserted main-step 
I insertion 1- Tt naturally arises when the turtle, while accomplishing 
one part of a model (the interrupted main-step), assumes an appropriate 
entry state for another part (the insertion). An obvious planning 
strategy Is to insert a sub-procedure at such a point in the execution 
of the interrupted main-step. Often, the insertion will be state- 
transparent: for turtles, this is achieved by restoring the heading r 
position and pen state, The insertion of the arms into the body by 
statement 3d of JiAFOLEQN is an example of a position- and pen- but not 
heading- transparent insertion- 

insertions do not sham all Of the properties of interrupts. For 
example h the insertion always occurs at a fixed point in tho program 
rather than at some arbitrary and unpredictable point in time. Nor does 
the insertion alter the State of the main process as happens in an error 
handler. However, If one focusses on the planning process by which the 
user's code was written, then the insertion as an intervention in 
accomplishing 4 main-step does hove the flavor of an interrupt. 

The FINDPLAN module aids the debugger In a second way beyond just 
tlie yeheration of the plan. This 13 through the creation of caveat 
comnents to warn the debugger of suspicious code that fails to satisfy 
expectations based on the abstract form of the plan. In particular* if 
FINDPLAN observes an Insertion that is not transparent, then the 
following caveat is generated: 

30 VEE <- (cavEat findplae (not (rotation-transparent insert)I)„ 

The non-transparent Insertion may have been intentional, e.g s the 
preparation far the next piece of the Interrupted main-step may have 



bocn placets within the insertion,. The user's program may haye prepared 
Tor the next main-step within the insertion. Hence, FINBPLAN dees not 
immediately attempt to correct the anomalous code. Only If subsequent 
dobugfllng of some model violation confirms the caveat is the code 
corrected. There will often be many possible Corrections for a 
particular modal violation. The caveat is used to increase the 
plausibility nf those edits that eliminate FIUDPLAW'S complaint. in 
this, way, the abstract fern nf the plan helps tn guide the debugging. 

For NAPOLEON,, analysis of (NOT (LINE fiOPV)) leads HYCRGFT to 
consider (1) adding a rotation as Statement 35 to align the second piece 
of the body with the first or {2} placing this rotation into Vtfc as the 
filial Statement, Ordinarily# linear debugging would prevent the latter 
as it does not respect the inviolability ef main- steps, However, it is 
chosen here because of the corroborating complaint of FINDPLAN. The 
underlying cause of the bug is a main-step error (non-transparent 
insertion) rather than a preparatory-step failure. Thus* 

(DEDUO (LINE BODY)) produces: 

70 HIGH! 45 <- (setup heading such-that (transparent vee)) 

1,7 GEOMETRIC KN OWL EDGE 

Linearity, preparation and interrupts are general problem-solving 
strategies for organizing goals into programs. HpwevEr, it is important 
to remember that domain-dependent knowledge must be available to a 
debugging system. The system must know the semantics of the primitives 
ir it is to describe their effects. 

The debugger must also have access to domain-dependent information 
to repair main-steps in which the sub-parts must satisfy certain global 
relationships. For example, IKttQR,N has the bug that the triangle is 
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not Closed. Each main-step independently achieves a side but the Sides 
do not have the proper global reletionship 4 Debugging is Simplified hy 
the explicit Statement in the model that; 

(FOR-EACH ROTATION (■ (DECREES- ROTATION) 120)). 

I5ut suppose the model imposed, no constraints on the rotations, then the 
dosiEin of the rotations would have to be deduced Tron such geometric 
knowledge as the fact that fi equal vectors fora a regular polygon if 
oath rotation equals degrees. 

The pieces of an Interrupted-Step such As tha first side of TRICORN 
are not always separated by a State-transparent insert, {This would be 
a local, interruption.) Instead, it is possible that mors global 
knowledge is needed to understand the properties of the intervening cede 
which justifies the expectation that the pieces will properly fit 
together, In TRICORN, the second piece {drawn by statement 70) must be 
coll inear with the first (drawn by statement 10). The global property 
of the code which justifies this is that «h|UA 1 S-ldfis and IZD degree 
rotations results in closure. Thus, debugging violations of globally 
interrupted-steps requires domain‘dependent knowledge, 

Geonetric knowledge: does not replace the need for general debugginu 
strategies: these are still very important to narrow the space of 
possible repair-points for correcting a given violation and to choose 
between alternative corrections. Section + discusses both types of 
knowledge in greater detail. 


2 . THE AMOTMOK 


Debugging is impossible without good description of a program's 
purpose and performance, KVCR.OFT begins with the program and a node! 
describing its intended result. Two forms of additional commentary are 
then generated; Performanre Annotation document& the effect of rubniPiu 
the program while the Platt explains the intent. This commentary is 
organized us sets of assertions in a database, bound together into 
sequences representing what- happened and why. Figure 2,1 shows part of 
the database generated to describe NAPOLEON. The nodes are organized so 
that the horizontal axis represents time and Is used to answer such 
causal questions as what changes occurred to which state variables and 
which coda was responsible for these changes. Similar data structures 
for describing progruHS are used by Fahlman [1973J and Sussman [1973]- 
The vertical axis represents teleological abstraction and 
explains the purpose of the cade. Models fit into this descriptive 
framework as the highest level of abstraction. They describe the final 
goal without ties to specific plans or chronological performance. The 
next level Is the plan, indicating the sub-goal organization for 
accomplishirig the model. Finally, the teleology rests on a description 
of the actual performance of the turtle program when executed in a 
particular initial environment. 

rtVcROFT analyzes a program by first building a complete 
performance annotation and then applying the plan-finder to assign 
purposes tp the code. Performance annotation is accomplished by running 
ttiH user's turtle program In a ^careful mode" which produces three kinds 


of description. 
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INITIAL ANNOTATION FOR NAPOLEON 


























1, Process Annotation is a description of the output of the 

program, Tt consists of a record of the effects of executing 
each program statement. For turtles, this consists of the 
Creation of vectors, vector structures, rotations and points. 

Z, Planning Advice suggests the segmentation of the program with 
respect to accomplishing the model on the basis of such 
Criteria as global connections. 

3, Debugging Advice describes suspicious code by caveat comments 
which aid in subsequent debugging. 

Details Of these three kinds Of performance annotation are givEn below, 
The FIHCPLAN algorithm is then described in section i, 

Z ,1 PROCESS ANNOTATION 

Process annotation provides a description of the output of 4 
program and Its sub-procedures in terms of Some language appropriate to 
the purpose for which the program was designed. For example, the 
performance annotation for an arithmetic program might be In terns of 
mathematical equations to be satisfied at various points in the 
computation J_Floyd 1967}, For turtles programs, an obvious choice Is to 
produce a Cartesian description of tha picture drawn hy the program. 
Annotation should reveal the basic effects of the code, free of vagaries 
of individual programming style. This would include knowing the 
description of a vector, regardless or whether the actual command is 
FORWARD, BACK or SETKY, (The last command moves the turtle to an 
absolute position op the screen.) 

Annotatioh produces a sequence of frames. A frame is generated 
to describe the execution of each primitive and sub-procedure call. 

Each frame is a set of assertions specifying (!) any changes to the 
turtle's state and (2) the properties of any picture elements wmch have 
been created. The turtle 11 s state consists of the values of the global 
variables [HEADING, 5 POS. IT lOM and :FEN, Picture elements (created as 
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side eff&ets of executing turtle commands) are vectors, rotations, 
points -and! structures (vector sets drawn by recognizable code segments 
such as sub-procedures). 


Z .Z SEMANTICS FOR TURTLE PRIHTT1VES 

The process annotation is generated by inperative semantics 
associated with each turtle primitive, These semantics describe the 
performance of the turtle coimaaud. 


SEMANTICS FOR (FORWARD ;DISTANCE) [Draws a vector. 

([VECTOR (GENERATE-NA}1E 'V) J 

[All vertices, rotations, vectors and structures 
;«re given, unique names to facilitate later debugging. 
lI f subsequent Investigation reveals that the 
;particular object has been given a label by 
[the Llsef, then the system name is replaced by the 
juser's identifier. 

[Describe the Vector in terms of its direction and length. 

(ASSERT (s (DIRECTION [VECTOR) SHEADING)) 

(ASSERT £= (LENGTH [VECTOR) [DISTANCE]) 

(ASSERT {• (VISIBILITY : VECTOR) <rENlJP, PENDOWSI, RETRACED 
;Update the State of the Turtle 

(:POSITION (FORWARD jDISTANCE)) 

[FORWARD [DISTANCE outputs coordinates of the new 
iposition. Set the turtle state variable [POSITION 
[to this new location of the turtle. 

([POINT <-- (GENERATE-NAME *P)) 

[If the coordinates are unique, bind :POINT to 
;a new name for this position. Tf not, use the 
;old name for the position. If a name already 
[exists for this position, record the connections 
[occurring at this point between [VECTOR and 
[previous vectors. 



SEMANTICS FOR (RIGHT : ANGLE) 


;Rotates the turtle. 


(: ROTATION {-- (GENERATE-NAME 'R)) 

;Describe the Rotation in terms of its vertex and degrees, 

(ASSERT (= (DEGREES :ROTATION} :ANGLE} 

(ASSERT (* (VERTEX :ROTATION} :POSITION} 

TUpdate the State of the Turtle 

( : HEAD I NT: <-- (RIGHT :ANGLE}} ;RIGHT outputs the new heading 
At the level of the process, actual numerical values are 
do tornlnod for the above properties. Because these assertions depend 
upon the particular state of the initial environment, this is the most 
specific, least abstract level of commentary when compared with the 
model and plan. 


2.3 PLAN-FINDING ADVICE 

Although performance annotation does not examine the model* It 
can rental clues to the grouping of the user's program into main- and 
preparatory-steps which aid in finding the plan- 

1, Sub-procedures that draw visible sub-pictures 
are hypothesised to be main-steps that accomplish 
s ome mo rle 1 par t. 

2, rtaxinal sequences of "invisible" primitives such 

as (a) vectors drawn either by retracing or with Eho 
pen op, (h) rotations, and (c,J PENLP connands are 
grouped together as possible preparatary-steps. 

3, Maximal sequences of visible vector instructions 
plus any intervening rotations are grouped as 
possible dain-steps. 

4* Global connections suggest code boundaries. Thus, 
maximal sequences Of visible vectors can he segmented 
oh the basis of such connect ions - 

This segmentation is tentative and may be revised in the light of later 
consideration of the model. 

Suppose NAPOLEON was not subroutini^eri. and, instead, the arms, 


legs and held were open-coded (i.c. coded as In-line sequences of 


primitives rather than subroutinized). The above clues would be quite 
Useful hy utilizing the global connections between the body and linbs in 
the picture to suggest main-step boundaries, 

Z- 4 DECLINING ADVICE 

Oddities irt the form -of the program can Create a suspicion of 
bugs, The annotator notices these violations using Rational Form 
Criteria which are Sensitive to unexpected and apparently erroneous 
code. Caveat comments are generated describing these complaints - 

Rational Form Criteria are based upon expectations of simple 
efficiency and Consist of noting sequences of contiguous uses of the 
same primitive, such as FORWARD, RIGHT or PENUP. The annotator 
considers the code to he odd: why didn't the user slmpLy coalesce thorn 
into a single call with a larger input or* in the case of RF.NUP, include 
only the first Instruction* Tne answer may he that the user has 
forgotten to insert additional instructions. An example would be where 
the Uter had forgotten to insert several RIGHT commands into a sequence 
of FORWARD instructions, A caveat stating that code may be missing is 
placed between each pair of elements in the sequence of FORWARD'S. A 
violation of rational form occurs in the following triangle procedure 
because the user has forgotten the first rotation, 

TO TRI 

10 FORWARD 100 (caveat annotator RATIONAL-FORK-VIOLATION 

(sequential-primitive 10 SAJI 

30 FORWARD IDO 
40 RIGHT 120 
50 FORWARD 100 
END 

An edit that inserts a rotation Into such a sequence of FORWARD 
instructions would eliminate the rational form violation and there Fore 


be preferred in conp a t j, t i on with other corrections which do not explain 
the annotator 1 ! conplaint. If the debugger Corrects the program by 
eliminating the annotation cavapt, then the underlying cause of the 
error is considered to be "Hissing Code'*, 


3, THt PLAM “FIWDER 


After performance annotation, the next step in describing the 

program is to find the plan. The strategy Is to attempt initially to 

find a linear plan,, i.e. to dutch model parts with modular main-steps 

and relations between model parts with preparatory-steps, This approach 

serves to Unit tins search space* but it is not adequate to recognize 

Interrupted main-steps and insertions. These N non-llnearitles" are 

suggested by suspicions about the cause of violations implied by the 

conjectured linear plan. Those suspicions are that the cause of the 

violation is not an error in the user's program but a mistake in the 

plan-fiurter's linear interpretation of the plan. If additional evidence 

confirms the suspicion, the plan-finder corrects its linear analysis and 

finds the correct global or insertion type of plan* This approach of 

first pursuing a linear interpretation and only 1 debugging’ this 

approach in response to anomalies is a powerful reasoning mechanism for 

searching complex spaces. As was noted in section 1, the debugger uses 

a Similar analysis to simplify finding the proper repairs. 

Plan-finding obtains some guidance from the picture and some 

from the program, The picture supplies such clues asr 

(a) global connections which suggest sub-picture boundaries; 

(b,) retracing which suggests inserts; 

and violations of model statements which are then used both as 
plausibility criteria l to dlistinquish between alternative 
In torprotat Lens> and to generate suspicion demons (which look 
for non-linear planning structures). 

The program supplies quite different clues about intent. This Includes l 

(a) sub-procedure structure which aids in recognizing main-stops; 

and £hji the order in Which the picture is dfuwo which, whan combined 

with program-writing criteria, suggests the order in which the 


/ 


model, parts arc acconplished 


3.1 PLAN-FINDING AS SEARCH 

Finding the plan can be conceptualized as a search nf a space nf 

H partial plans" L The search begins with the model, the program and the 

performance annotation, A partial plan it an explanation of some 

fraction nf the model In terns Of the program. Given a partial plan. 

Its daughters are the result of generating alternative explanations for 

one of the remaining unassigned mode) parts. A terminal node is reached 

when all of the model parts have been Explained and a complete plan is a 

path from the root to a terminal node, wherein an explanation is 

provided for how each model part is achieved, 

A partial plan consists of PURPOSE comments which assign model 

predicates to code, un assl gned nodal parts, expectations, the Implied 

partial interpretation, and demons. 

PURPOSES - These arc the basic statements of a plan and appear as 
commentary In the NAPOLEON procedures. Five kinds of purposes 
are generated by F1JJDPLAN; accomplish, insert, setup, cleanup and 
retrace. 

UNA5510NliG HOPEL PARTS - The mpdel specifies a list of parts. These 
are either primitive picture objects (vectors or rotations J or stub- 
models. An unassigned part is one without a PURPOSE statement 
indicating how it is tP he accomplished. 

EXPECTATIONS - These are predictions of which part is expected to he 
accomplished by the next naln-step. They are based on applying 
program-writing criteria nf efficiency and simplicity to the madel. 
See the discussion o-f Analysis by Synthesis in the next section, 

PARTIAL INTERPRETATION - flodel predicates can he evaluated by 
ordinary Cartesian geometry using the binding of model parts to code 
(which the plan implies) and an annotated description of the code's 
effects. A partial interpretation consists of those model 
predicates whose truth value is known given the current partial 
in torpretation, 

DEMONS - Demons are used to explain subsequent code in such a way 
that violations in the partial interpretation are eliminated- The 
elimination results from debugging the system's linear analysis and 


recognizing the existence or an interrupted or inserted main-step. 


Ihc partial plan is completE when all of the unassigned parts 
are explained by PURPOSES, Debugging Is fixing the v id 1 atibn s of the 
resulting complete interpretation. 


3.Z LINEAR PLAM SPACE 


The search is neither a standard breadth nor depth first 
exploration of the space. Instead* the system initially assumes a 
linear structure to the user's plan, looking to assign the parts to 
sequential code segments. The possibility that a part is heing 
accomplished by disjoint segments or code or by insertions is not 
considered, Tb\s greatly constrains the search Space. Branching, 
however, is not eliminated r for a given program, more than one linear 
plan will usually be possible. To ChOOSB among the alternatives in this 
linear pinn Spues, several plausibility criteria are used- 


1 


(Advice} The first is to take advantage of user, annotator or 
debugger advice to initialize the partial plan space. Annotator 
advice originates in noticing (i) sub-procedures that have boon 
previously associated with a model and (2) open-coded sequences 
identified as having a common purpose on the basis of non-model clues 
like penstate changes and retracing. (See section 2.3.} The first 
produces PURPOSE assertions which form the initial partial plan: the 
second SlXiC£5TiQk'5 which have the effect of causing open-coded 
sequences to be treated as sub-procedures, Debugging advice Is in 
the form of a request that tile plan-finder supply a new plan that 
does not mak-o certain hypotheses about the program. This interaction 
arises when the debugger finds all editing strategies for the current 
1 an im p 1 au s ib 1 e , 


2, 


(Analysis by Synthesis 
the point of view of p 
advice. The first is 
possible (on the group 
plan for breaking the 
generate expectations 
accomplished. This is 
predicates us BELOV an 
that that these sequen 
parts are accomplished 


) Another method is to consider the model from 
rogram writing. This leads to two forms of 
to assign sub-procedures to model parts if 
ds that the model parts constitute a likely 
picture into sub-goals}. The second is to 
for the order lh Which the parts are to be 
done by Observing transitive sequences of such 
d -CONNECTED in the Bodel. Tho heuristic is 
CES represent the probable order in which the 
, thereby *intmliing retracing. 


3, (Static Evaluation Function) A third rsethnd is. a plausibility 
estimate of partial plans* This estimate is simply the number of 
satisfied model statements and expect inns minus the number of 
violated modal statements and expectations. if the program is bug 
free and the plan is correct, then the plausibility number will be 
maximal,, At any instant in time, only those plans with the highest 
plausibility number are explored After analyzing a Statement of 
code, the plausibility number is recomputed and the active plans are 
rechosen- Inactive plans are ■hung" and are ngt resumed unless their 
active brethren become less plausible. 


3.3 FI HD Tire THE PLAN FOR STIC KHAN 

As an example, let us consider the problem of finding the plan 

for NAPOLEON. Recall that the procedure is; 

TO NAPOLEON rSee figure 1.1 

ID VEE 

RP FORWARD 100 
30 VEE 

40 FORWARD 100 
50 LEFT 90 
60 TRICORN 
END 

We shall assume that the VEE sub-procedure has been previously annotated 
and associated with the V model but that TRICORN and NAPOLEON have just 


beer defined and their purpose 14 unknown. By considering sub- 
procedures as candidates for accomplishing model parts (analysis by 
synthesis), TRICORN is bound to the EQUiTRI model. The result IS two 


possible initial partial plans. These aren 


PARTIAL.FLAN. 1: 

10 V£E <- (accomplish legs) 

30 VEE o (acconplish arms) 

60 TRICORN <- (accomplish head) 


PARTIAL.PLAN.2: 

ID VEE <- (accomplish arms) 

30 VEE <- (accomplish Logs) 

50 TRICORN <- (accomplish bead) 


Furthsr constraints are imposed hy FINDPLAN's program-writinn 


expectations. On the basis of BELOW, FINBFLAN expects: 

(accomplish legs) <-> (accomplish arras) <-> (accomplish heat)) 
The double arrow indicates that the sequence nay happen in either 


forward or reverse order. On the basis of connoctlvity 3 tho 
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expectations are: 

(accomplish logs) <*> (accomplish body! 0> (accomplish head) 

Taken together* the result is that statement ID is believed to 
accomplish the LEGS and statement 30 the ARMS, Thus, PARTI At. PLAN, l is 
preferred, 

Tha code of the program is then considered statement by 
statement, Statement 20 draws a vector and is therefore helieved to be 
the BORV. It night be only a piece of the body but this is not pursued 
until th,o linear assumption that the body is accomplished 6y a nodular 
main-step Is rejected. 

Statements 30 and 60 have already been assigned tn the arms and 
head, respectively. As a result, all of the model parts have been 
assigned but statement 40 remains unexplained, FINDPLAN consequently 
backtracks and interprets Statement 20 as only piece of the body, A 
demon is created for recognizing the body's completion and plan“finding 
recommences at statement 30, Statement 4D satisfies this demon since It 
draws a vector that begins at the endpoint of the first piece oF the 
body, The result is that it is considered (Piece Z body), Thus, with 
almost no search, the plan for NAPOLEON Is correctly deduced. 


TO NAPOLEON 

<* (accomplish man) 


10 VEE 

(- (accomplish legs) 


20 FORWARD 100 

<- (accorplish (piece 

1 body)) 

30 VEF. 

<- (Insert arms hady) 


40 FORWARD 100 

<* (accomplish (piece 

Z body)) 

50 LEFT 00 

<- (setup headiny] 


GO TRICORN 

<- (accomplish head) 


ENr* 




3.4 h'ON-L SHEAR PLANS AND SELF CRITICISM 


Tins section explains how interrupted and Inserted main-steps 
are recognized, Uben F1NDPLAN binds nn unassigned model part M to a 
SBfjDeot of code C and the resulting interpretation implies model 
violations, there are three possible explanations: 

1. The code is in error: a bug has been discovered* 

Z, C is not intended to accomplish 1. Choose another interpretation 

for C, 

3. C accomplishes only a PIECE of h. The remainder of M is achieved 

in pieces. 

Possibility 1 requires no special action by FINDPLAN: the 
violation will eventually be passed to DF.BLI6 for correction. 

Possibility Z requires that the a different linear plan be chosen. This 
will occur if the current linear plan becomes less plausible than 
alternative linear interpretations when compared in terms of the static 
plausibility function described earlier. Possibility 3, however* 
represents an error in the plan-finder's linear analysis of the program, 
Nonce, to take account Of possibility 3, damns are generated. These 
demons are looking for better interpretations than the current linear 
plan (1,0, interpretations which do not imply as many violations). The 
following paragraphs describe the creation of such a demon in the plan- 
finding process for TRICORN, 

Suppose FINPPLAN has just decided that statement C achieves 
model part H and that this results in a violation because H is ton 
snail. FIND PLAN suspects that N nay be being accomplished in pieces, A 
COMPLETION denon is created looking for subsequent CPde CC Which would 
eliminate tha violatioti if CC is interpreted as another PIECE, of M, If 
such code is found, the action of the demon is to edit the original 
partial plan so that M is now considered 9S being achieved by an 
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interrupted main-step. IT the Code between the pieces of the ma i n - $ t op 
returns the turtle to the exit state of thfl first piece, thee it is 
interpreted as being an insertion. COMPLETION demons are also created 
when a vector is too short to accomplish an intended connection. An 
example occurs In the linear interpretation of TRICOftN shown helow: 


TO TRICORN 
10 FORWARD 50 
ZQ RIGHT 120 
30 FORWARD 100 


; Incorrect linear plan initially deduced. 
<- (accomplish (tide l)) 

<- (accomplish (rotation 1)) 

<- (accomplish (side 2>) 


:At. this point in the plan-finding process, the violation 
;of unequal sides occurs* A COMPLETION demon is created 
;that is looking for a vector of length 50 that could he 
3 interpreted as the remainder of (side 1). 

10 RIGHT 120 < - (accomplish (rotation 2)) 

SO FORWARD 100 <- (accomplish (side 3H 

■Here the violation of (side 1) not being connected to 
;lside 3) occurs- A second COMPLETION demon is created 
[that is looking for another PIECE uf (side 1) that connects 
lto (side 3 J . 

60 RIGHT 120 < - (accomplish (rotation 3)) 

?<s FORWARD SO <- (accomplish ?) 

END 


Both of the COMPLETION demons are triggered hy statement 70. The result 
is that statement 10 is reinterpreted to accomplish only 
(piece 1 (side 1)) and statement 70 is assigned the purpose of 
accomplishing (piece 2 (side 11). This produces the correct plan, 

(Other demons are created in the plan-finding process for TRICORN 1 . 
However, they are never triggered and are therefore not mefttidhed.) 


3.5 SUnHAfty OF THE PLAN^F1 *JDF.R 

The algorithn for plan-finding performs well when: 

(.1) The user supplies advice in the form of A partial plan: 

£2) The procedure has subroutines^ 

(3) The procedure has few bugs- 

If the program Is not subrout ini zed and is full of bugs, the search 
grows unmanageable and difficulties arise in selecting the most 
plausible candidate. This performance is quite reasonable in the sense 
that similar statements are true of a human problem solver invest!gatirg 


a strange proyram. 


4, THE DEBUGGER 

4.1 MOREL VIOLATIONS 

The monitor is designed to debug raodel violations. These ar& 
recognised by the INTERPRET module (see again figure l.fij which compares 
the output oT a syntactically and semantically correct turtle program 
Ci.e. a program that is able to run to completion without requesting any 
illegal computations) to the description of intent provided by Its 
picture nodei f Using the plan to bind sub-pictures to model parts. The 
result is a list of violated model predicates, The program is 
considered correct when all of these violations have been eliminated. 

Correcting model violations is accomplished by using two typos 
of procedural knowledge: (!) a collection of general debugging 
strategies for repairing programs and 12) directions for fixing 
particular geometric and logical predicates. Because overall sjuidrtiiCe 
is derived from the model, we shall cell this type of aholysis model- 
driven debugging, 

4.2 DEBUGGING AS SEARCH 

A debugging strategy is a sequence of editing commands whose 
effect is to modify the program so that it satisfies its model. There 
are generally multiple debugging strategies for correcting a given set 
of violations. These alternative debugging strategies arise from choice 
of the repair-points at which the corrections are to be made as well as 
of the OKact meaning that the user intended. 

To clarify the issues which arise In selecting the best 
debugging sequence, it is useful to conceptualise the problem in terms 
gf a search metaphor. The space Is that of all possible debugging 


strategies for correcting the program, Each node is a set of model 
violations: the origin of the space is the initial output of INTERPRET. 
An Arc is an edit which which leads to a node containing the- new land 
presumably smaller) set Of Violations which are produced by the patched 
code. Branching occurs for each possible patch for correcting a 
violation. A path through the space constitutes a series of edits that 
t-ran & Term the program to an acceptable form. 

Recognizing the existence of multipie possibilities for 
correcting a program,, it is appropriate to asK what knowledge is used 
to: 

(1) choose the noKt nodal violation to be dubugnud? 

(Z) generate the passible corrections far that violation T 

1 d) choose the most plausible correction? 

The following sections answer these questions. Ordering 
Criteria are introduced for thooslug the t e ituence- io which the 
violations are debugged, A Linear approach curtails the number of 
possible edit points which are initially considered. The imperative 
semantics of the mndel predicates are used to generate possible 
corrections. Plausibility criteria are designed for selecting among 
alternative debugging strategies. 


4.3 ORDER INtr MULTIPLE VIOLATIONS 


Multiple bugs ar« difficult to fix. Guidelines are required t* 
order the sequence in which the violations are debugged. These 
guidelines reflect an understanding Of dependency relationships between 
vitiations* thereby serving to minintze the unfortunate occurrence or a 
correction undoing previous repairs or introducing new violations. The 


ordering is donE on the basis af preferring to repair? 




( 1) bugs in properties of mOdGi parts before bdgs 
in. relations between model parts; 

(3) buys in intrinsic properties (or relations) before 
bugs in extrinsic properties (or relations); 

and (1) hugs occurring earliest in the temporal Seguetice 
of execution. 

The following paragraphs describe these criteria and explain their 

rationale. 

A . 3 .1 Debug Properties Before Relations 

The system debugs delations of properties of model parts before 
repairing violations of relations between nodel parts. This is based on 
the important heuristic of first having a successful theory of the parts 
before attempting an explanation of the it- interactions. This is more 
than good style. The behavior of the interfaces is designed relative to 
the ontry-axlt states of the ecdo for the main-steps accomplishing the 
parts. To determine the specific State changes to be made at an 
in turf ace, the performance of adjacent mftin-Stcps must be established. 
Thus the code for sub-pictures must be fixed prior to deciding on the 
proper edits to the preparatory-steps. 

Properties of individual model parts include unary nodel 
primitives (e.g, VERTICAL. HORIZONTAL and LINE) as well as user-defined 
sub-models (e,g, EqUlTKi and V). The most common relations between 
model parts are predicates such as ABOVE, BELOW., and CONajEfTEli- 

4_.3.Z Debug Intrinsic Before Extrinsic Predicates 

The idea behind the next ordering criteria is to estimate the 
range of possible locations in the program at which the repair might be 


made for each violation. The heuristic is then to fix those violations 


of most-Limited scope first; both because they are easiest and because 


of dependency relationships. 

Let the scope of a violation be the code between the repair- 
point and tha manifestation-point. For a property CP M), K a model 
part, the manifestation-point is the location In the program at which M 
is completed and the truth of the statement (.P can be evaluated. The 
repair-point Is the location in the program at which the edit is 
eventually made to correct the violation. For a relation (R K N), the 
manifestation-point is the location in the program, at which both rl and N 
have been completed and the relation R can he evaluated. 

This criterion would be pointless if there were no way to 
estimate the scope of a violation before entering into the details of 
debugging, However, this is not the case. One method for estimating 
the scope of a violation is to know whether the property of relation is 
intrinsic to the responsible code, 

A property (P A} is intrinsic to the code for A if it is 
independent or preceding code and entirely due to the main-step for A, 
Similarly* the relation (R A is intrinsic if it is independent of 
code preceding A, assuming that A is achieved beroro B. Repair is 
simplified by fixing intrinsic predicates before extrinsic ones since 
11 ] Tor intrinsic violations, the possible repair-points aro easier to 
find since they cannot occur prior to the code for A, and {2} the proper 
corrections for extrinsic predicates depends upon the the code being 
intrinsically correct. 

In the world of turtle geometry, intrinsic errors are 
distinguished by being independent of the frame of reference! they 
cannot be corrected by translating or rotating the picture. This is 
because in the simplified environment of fixed-instruct!on turtle 



programs. code groups draw rigid bodies, fhb initial interface of a 
code group has the effect of eitibltjhUg the origin and orientation of 
the sub-picture hut does not affect the local relations Among vectors. 
Topological predicates {invariant under transformations that preserve 
connectivity) and geometric predicates (invariant under translation anti 
rotation) are independent- of the frar.e Of rsferonco and therefore yield 
Intrinsic violations. Bugs in the fnllosing model primitives are always 
intrinsic to the code group to which they refer: OVER[-AP. INSIDE* 
OUTSIDE. PARALLEL and CONNECTED, 

Extrinsic errors are those affected by the Initial Environment 
In which the code group Is executed. The initial environment consists 
of the bindings of the turtle state variables — ifltADINb, ;P0£JTI0N and 
;P£N, These variables control the* orientation t origin and visibility of 
the Sub-picture as well us its relation to previously drawn parts of the 
picture. Modal predicates which depend on the initial state are 
VERTICAL, HORIZONTAL, BELOW, and ABOVE„ 

Debugging intrinsic violations first tends to establish the 
proper connections at interfaces. Debugging extrinsic relations like 
ABOVE then becomes simply a matter nf establishing the proper heading at 
interfaces, 

In the turtle world, the distinction between intrinsic and 
extrinsic predicates Is particularly easy to make; however, it remains «, 
useful debugging distinction in other domains, If a property of a 
program is due to some local data structure (such dS a bound variahle) 
or local control structure {such as a loop) and is independent of the 
preceding cede* then it is intrinsic and worth debugging in private 
before extrinsic properties {whose causes are less easy to Isolate) are 


repaired. 


4,3,1 NAPOLEON'S Violations 


The following list of violations far NAPOLEON is ordered by the 
above criteria^ 


(Violations of Properties of 
(An Intrinsic Violation 
(NOT (EQUITRL TP KORN J) 


Parts of NAPOLEON) 
Manifested in Private) 


(An Extrinsic Violation 
(NOT (LINE BODVJ) 


Not Manifested in Private) 


(Violation* of Relations between Parts or NAPOLEON) 

(Temporal Order -- (legs, arras} accomplished before (arms, head)) 
(NOT (BELOW LEGS ARMS)} 

(NOT (BELOW ARMS HEAR)) 


4.4 FINDING THE PROPER REPAIR-POINT 

For each violation, DEBUG must find the proper repair-point id 
the program at which to insert the correction. Of course, the debugger 
Rgows that the repair-point cannot follow the code for the parts 
men t to tied in the violation hut this is hardly j sufficient constraint. 
Consequently, DEBUG uses two hearistics--Private and Linear Debugging-- 
to limit the possible locations for the correction, 

4.4.1 Private Debugging 

An initial heuristic for constraining the possible repair-points 
for a violated property is to limit consideration to the code directly 
responsible for the model part in question. This is done by running the 
responsible code independently of the larger procedure or which it is a 
part. Specifically, the responsible code is executed with tho turtle 
started at the entry state- The violated properties will be manifested 
In this private environment if the main-step is modular. However, if 
there is intervening code, i.e. the main-step is interrupted, then the 


linear assumption that the cause la intrinsic; to the responsible code 
and not due to interactions may be wrong. 

If the violation is manifest, the code group Is then debugged in 
tills simplified context. Tree of the effects of the remainder of the 
original program, Private debugging is used to repair the three 
incorrect rotations of TRICORN. There are no complications when the 
edited Sub-procedure is rejoined to the NAPOLEON super-procedure. 

The relationship between the picture drawn in private and in 
public Is simple for fixed-instruction turtle programs since the picture 
is a rigid body and only its orientation and origin is affected by the 
initial environment. For more complex programs, difficulty occurs in 
finding a representative private environment and further research is 
necessary. This is similar to the problem of diagram generation in 
geometry theorem proving and to the problem or case analysis in 
automatic program vorificatlon. 

The private repair may nakE assumptions about the entry state to 
the cade, if this happens, it will be reflected in comments 

regarding the entry state to the main-step. When run again in the real 
contest* any conflicts between assumptions mode in private about the 
Initial environment and the actual entry state are themselves debugged. 
This is accomplished by adding code to accomplish the assumptions in the 
super-procedure or, if this proves impossible without causing additional 
violations, backtracking and attempting an alternative correction in 
.private. 

An example of this would occur if the model for NAPOLEON had 
declared that the body must be vertical.. Debugging the body t statements 
Z 0 and “10) in private would result in the assumption being generated 
that the entry heading must be 0 or 180 degrees. The code for the body 


ii then reconsidered in the context of the NAPOLEON super-procedure- 
The actual entry state t-g statement 2D dees not have :HEADING equal to 0 
or LOO degrees, Consequently, the debugger now attempts to add a 
rotation at some preceding point in the program to achieve this entry 
■state. This addition Will most lively occur immediatoly prior Id 
statement 30 or, perhaps, as the initial setup to the NAPOLEON program. 
The debugger chooses whether to prefer 0 or LSD, and at which repair- 
point, on the basis of side effects, minimal change to the user's 
program and planning caveats. This set of plausibility criteria is 
described in section 4.7, 

The system) also checks for bad side-effects on code To 1 lowing 
the edited sub-group due to a new exit state for the edited code. A 
Cleanup step may be needed to eliminate undesirable consequences uf the 
private repairs. The modified main-step may violate protection or 
assumption commentary generated by other edits. If so, the standard 
practice is to either (1) modify the offended edit in light of the new 
structure for the main-step or [£) backtrack, and correcting the rtaiti- 
step in private In some alternative way, See section 4,6 for details on 
the protection mechanism. 

Occasionally, when the code is run in private, the violation 
does not occur. This happens because the main-step is not modular and 
the violation is due to coda appearing between pieces of an Interrupted 
main-step. Private debugging remains useful, however, because it 
clearly indicates that the cause of the error is in the intervening 
code, {NOT (LINE BQDYJ) is an example’, the body when run in private is 
indeed a line. The bug is in the effect of the inserted VEE oei the 
heading of the second vector. 

Private debugging is also used to correct intrinsic violations 


of relations. Bacall that the definition of an intrinsic relation is 
that it is entirely due to the code between the model parts mentioned iil 
the relation. Henee 4 the repair-point must occur there. The seme 
precautions required when the code is rejoined to the supor-proceduro-“ 
i.e. satisfying assumptions, and possibly cleaning up--must be taken. 
Outside the turtle world where it may not be so easy to decide if a 
relation Is intrinsic, private debugging can still bo attempted. Just 
as rur properties„ IT the violation does not appear ill private, then it 
is known that it is not intrinsic and the system can look for causes in 
preceding code, 

4 A.Z Linear Debuygirtg of Relations 

Linear Debugging is a technique far limiting the possible 
repair-points for correcting violated relations of both the intrinsic 
and extrinsic kind, It is based upon the assumption that flEBIMi has 
already privately repaired the main-steps to satisfy their properties- 
The linear debugging technique Is to consider editing corrections only 
at preparatory-steps and not internal tp the code for the main-steps, 
ttaln-staps are treated as inviolate black-boxes: their contents need 
neither be known nor changed. This is based upon the assumption that 
the pain-steps are independent and that the only corrections necessary 
to repair relations is to make adjustments at interfaces. This was the 
technique used to debug (BELOW LEGS AflME) . DEBUG limited the search for 
the proper adit by not considering the addition of u rotation to the 
interior of the VEE Sub-procedure, instead, it restricted itself to an 
analysis of possible corrections at the level of the WAPQLEOW super- 
pro ce (hi r 0 , 

Linear debugging fails when the underlying cause of the 



violation is due to the code for ore of the parts. In such a case, it 


i£ necessary to remove the restriction against modifying main-steps. An 
example where this occurs was shewn In figure 1.5. The violation of the 
mouth not being inside the head is caused by the size of the mouth, not 

hy the interface- 


4,5 IMPERATIVE KNOWLEDGE 

How is the set of possible edits for repairing a violation 
generated? The answer lies in the use of procedural knowledge 
associated with the model primitives which provides direction on how to 
note the predicate true. The system has imperative knowledge for 
logical primitives like equality and conjunction as wall as for 
geometric primitives appropriate to the turtle world. This imperative 
knowledge outputs a set of possible edits whose effect is to eliminate 
the violation. 

In the NAPOLEOH example, [NOT (EQUITRI TtttCOftll)) Is a violation 
Of d user "ltd del, such violations are fixed by recursive entry to the 
debugger and analyzing the code for the model in private. Such 
recursion ultimately reduces the debugging to fixing violations of model 
primitives, 


4.5,1 Imperative Knowledge for Geometric Primitives 

The following discussion describes in s simplified way the 

imperafive knowledge associated with several of the model primitives. 

Let X and V be vectors and assume that X is accomplished! before Y . 

(.1.1 MR X V) <=> (AMD (PARALLEL X Y> (CONNECTED H)) 

The Imperative semantics for AMO directs debug to establish the two 
relations of PARALLEL and CONNECTED, These are defined below. 


(PARALLEL X Y) <»> (■ (DIRECTION A) (DIRECTION II) {ftOD ISO I) 


The annotator rtcsrds the DIRECTION 1 or vectors. The repair is to 
Insert rotations- between the code for X anct the code for Y so that 
the direction of Y becomes equal to the direction of X (mod ISO). 

(VERTICAL X) <*> (OR { = [DIRECTION X) D] (■ (DIRECTION X) IflO)} 

Alter preceding rotations so as to make the direction of X 0 or I Art, 

(CONNECTED X Y) 


Choose j connect Ion p&int on X {PI) and a connection point on Y 
(P-2)., The connection point is sometimes specified In the model] for 
example* the user aay have indicated that it should occur (AT 
(HIDOLE (SICE Then Compute the vector V from PI to PZ. The 

edit is to add code for v into an interface between X nod Y, This 
will have the effect of translating V so that Pi is moved to 
coincide with P3, 


If the exact position is unknown, deduce it from ■constraints such as 
preferring to effect the code in minimal ways. This Is done by 
manipulating individually the length and angle inputs to translation 
and rotation interface steps (occurring between the code for X and 
the code for V) and observing if X and Y intersect as a result. 
Branch in considering alternative allowable connection positinns# 


(ABOVE X Y) - (similar technique for BELOW. RIGHT*OF, LEFT-QF) 

To compute the required correction for a given interface; assume 
that the figure has already been debugged to be topolosleally 
correct--e.g. all of the connections are correct. This implies that 
the only degree Of freedon in interfaces is the heading. 

In considering a given interface, find the range of headings which 
satisfy the predicate. The range is determined by first finding the 
heading of most restrictive meaning of ABOVE — CENTERED-ABOVE 
wherein the center of gravity of X is directly above Y r Then relax 
this heading to find the maximum range in which less restrictive 
roe lining s or the predicate- - C0P2P LET E LY - Af&DVE and PARTLY -ABQVE--remaih 
true. To select a specific heading to Actually edit into the code* 
choose the value that satisfies the mbit, restrictive meaning of 
ABOVE, If there is still a range of possible headings, use the 
average value, Record the range considered in case later debugging 
results in Conflicts and another heading rsust be chosen. 


4_„ 5,Z The Rigid Body Theorem 

Fixed-instruction turtle programs draw rigid bodies, i e. the 
only effect of the Initial runtlne environment is to alter the 


visibility, origin or orientation of the frame of reference. This 


theorem simplifies the generation of possible repair edits by allowing 
computation of the required rotation for HORIZONTAL, VERTICAL and 
PARALLEL to he made only once, independently of the point in the code at 
which the edit is to be added. This is useful since there are usually 
many points at which patching the code mM&t be considered to fix those 
violations. 

For example, suppose the side of a triangle is to be made 
horizontal. The required rotation is computed for the side. However, 
if the edit is made immediately prior to the code Tor the side, the 
triangle shape will be destroyed. The rotation, however, can be added 
to preceding code, rotating all subsequent vectors the same amount, and 
consequently still making the side horizontal. 

In general, IT the Correction is a rotation of the frame of 
reference, the edit can he added anywhere prior to the code group to bo 
rotated. If the rotation is to change the relation between two sub' 
pictures, then it tan often occur anywhere in the code occurirvg between 
Clio main-steps which accomplish the Sub-pictures, 

4,5,3 Imperative Knowledge of Logical Predicates 

The general advice for fixing £P A) {P B)| is to use the 
imperative semantics for property P to either make [P AJ equal to (P tel 
or vice versa. For the simple case of fixed-instruction turtle 
programs, the change Is usually made to A or V on the basis of which 
occurs last. This is preferred because of the rigid body nature of sub- 
pictures. For example, suppose A occurs before l!. Then adding Pl&llT 
;ANGLE before A rotates A but it also rotates B. An opposite rotation 
must be added after A if B is hot to be affected by the first edit. 

Thus, fixing the sub-picture which occurs first commits the system to 


two chanties of the pro-gram, Of course, editing the code before 6 may 


also require a cleanup because of bad side effects but tbls is not 
inevitable as it is in the first case. This preference is reflected in 
the general debugging criteria of avoiding conflicts, minimizing change 
to the user's program and preferring beneficial side effects. 

Thus, filing equality consists oft 

General Knowledge: Either A or & can be fixed, 'Prefer to alter the 
unprotected element (section 4,6}. 


Domain-Dependent Knowledge: Imperative semantics are provided for 
relating primitives to their effects. These semantic* are used by 
the annotator to document the effect of a statement of code, and by 
the debugger to add the correct code to achieve a desired effect. 

For example, to alter the direction of a vector, the annotation 
semantics for Forward (section 2,2) indicate that the DIRECTION 
property of vectors is equal to the current heading. The uiinotdtlOfl 
semantics for RIGHT Indicate that :HEADIWG is incremented by sANC-Lli 
following execution of “RIGHT :ANGL£ M , The conclusion drawn by the 
debugger, then, is that either "RIGHT :ANDLE" is needed to fix the 
direction of & or "RIGrtT -:ANGXE* is needed to fix the direction of 
A, where :ANGLE equals the difference between the desired direction 
and the actual directian. 


To fix (AND Cl CZ ,,, ), correct all of the conjunct!, Order the 
debugging attack on the basis of the same Criteria Used to order the 
initial set oT Violations, Correct properties of maih~steps before 
correcting relations between nain**teps- Correct intrinsic before 
extrinic predicates., Debug a given group of conjunct* at the same level 
(With respect to the preceding criteria] in temporal order. 

See [Goldstein 1974j for a description of imperative semantic* 


for other nodel primitives such as INSIDE, OUTSIDE, OVERLAP, OR, NOT and 
FOR-ALU 


4,6 ASSUMPTION AM) PROTECTION 

DEBUG generates assumption and protection commentary associated 
with each repair to aid in resolving difficulties where an edit causes 



new violations or undoes the effects of some previous edit. Assumptions 


about the entry state at the repair-point describe expectations on which 

the Imperative semantics based their analysis. Protection comncntary 

cjdnrds the code lYota the repair-point to the mini Testation-pc in t (the 

place in the cede at which the sub-pictures referred to by the violated 

model predicate were completed), again because the details of the repair 

depend upon the State manipulations of the cede between the edit and the 

man)fnotation-point, Prelection is introduced by Sussnan in the context 

of debugging blocks world programs LSusSman 1973J, 

A simple example arises for the following tree program: 

HQ DEL TREE ;See figure A. 1, 

HI PARTS TOP TRUNK, 

HZ LINE TRUNK 
H3 F.QLJITRI TO? 

H4 VERTICAL TRUNK 
NS CONPLETELT-BELOW TJiljNIC TOP 
HC CONNECTED TUP TRUNK 
N7 HORIZONTAL ( BOTTOfl [SIDE TOP)) 

END 


TO TREE4 
10 TRIANGLE 
30 RIGHT 60 

JO FORWARD 5D 
40 RIGHT 45 
50 FORWARD LOO 
END 


C- (accomplish trefl) 

<- (accomplish top) 

C- (setup heading such-that 

(overlap (interface statement 00) (side 0 top))) 
<- (retrace (Side 3 top)) 

<- (setup heading for trunk.) 

<- (accomplish trunk) 


TO TRIAKGLE 
10 FORWARD 100 
ZD RIGHT 120 
30 FORWARD 10® 
40 RIGHT 120 
50 FORWARD 10® 

00 RIGHT 120 

END 


<- (accomplish equltri) 

<- (accomplish (Side 1 triangle)) 

O (accomplish (rotation I triangle)) 
O [accomplish (side Z triangle)) 

<- (accomplish (rotation Z triangle)) 
<- (accomp1is h (sids 3 t rian g le)) 
(cleanup position) 

<- (accomplish (rotation 3 triangle)) 
(cleanup heading) 


See figure 4.S Tor the picturE drawn by TREE4 with the turtle starlinjJ 
at the center of the screen and with a beadinU of 2 er 0 degrees. 



Intended TR£I 


TREE 4 
VERSION 1 

Slanted Rase and Trunk 


FIGURE 4.1 


FIGURE 4.Z 



TREE 4 
VERSION £ 

Ease Matte Horizontal 
FIGURE 4.3 



TREE 4 
VERSION 3 

Trunk Hade Vertical 
F3 EURE. 4.4 







Debugging the base of the TOP to be horizontal results in the 
addition of statement S to rotate the triangle so that the necessary 
orientation, is established- this produces figure 4-3. 

5 RSGHT 3-0 <- (setup heading such-that (horizontal (side 3 topi)) 
Debugging the TRUNK, to be vertical by modifying the initial setup, 
however, undoes this correction [figure 4.4)- 

3 RIGHT 4& <- (setup heading such-that (vertical trunk)) 

The so lot inn is for the initial correction of (HORIZONTAL (SIDE 3 TOP)) 
to include tocmentary explaining its purpose, scope and assumptions. 
Spccifically, this commentary it: 

1- an assumption that the entry state to Statement 5 is :HEADlNQrQ: 

(ASSUME (TREE4 STATEMENT 5) (= :HEADING D ] ) . 

2 - a protection to any modifications of iHEADING from Statement 5, the 
repair-point, to statement 50 of TRIABLE, the manifestation-pnjnt 
ef the error: 

(PROTECT :HEADiNG UNTIL (TRIANGLE STATEMENT 50)). 

Statement 50 is the manifestation-point of the error since it 
accomplishes (side 3) and INTERPRET Is then able to recognize that 
a violation exists“the base of the triangle is not horizontal. 

These comments force the debugger to prefer the alternative repair 

strategy of making the trunk vertical by editing the rotation of 

statement 40 to be RIGHT 90- 

A second use of this commentary, in addition to preventing 

conflicts between edits. Is to Simplify debugging the procedure if it is 

ever run in a new environment. Unsatisfactory initial state values aro 

1 hihied 1 ateLy noticed by the assumption Commentary- For example, if 

statement 5 of TREE4 contains the assumption that, the entry heading 

should be 9, then being run in any other environment will generate a 

violation- This Violation then directs the debugging. 

Thus, previous debugging sessions produce commentary whose 
specificity eliminates complex questions of responsibility and 
interpretion- The system has, in effect T generated the 
snapshots of performance which Naur and Floyd utilize to verify 
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programs I. Floyd 196 7 T Naur 19d7J. 

The as sumption crimen t is passed to the debugger as *R instruction and 
the result is that erode Is added prior to statement 5 which converts the 
heading to the desired value, 

Often a protection conflict can be resolved. The debugger is 
simply recalled to achiava the edit which gave rise to the protection, 
taking into consideration the new entry or exit state requirements* 

This second tail to the debugger involves less effort than the first. 

The c crimen t ary from the first remains and indicates th.e desired 
Cartesian state to foe achieved at the juanif as tat ion -point, If the 
second edit succeeds without causing on fixable vtolations as side 
effects, then the system has patched its own adit and need not reject 
the basic form Of its current analysis- 

4,7 DECIDING BETWEEN ALTER N ATIVE DEBUGGING STRATEGIES 

Plpre than one debugging Strategy is usually available to fix a 
given violation. The strategies differ with respect to their estimate 
of the failure point and with respect to the type of correction they 
apply to fix a given model violation, For example t the imperative 
semantics for BELOW indicate the desired direction but allow the 
correction to be added into any prior interface. In NAPOLEON t the arms 
can be made above the legs by adding the appropriate rotation to the 
beginning of the NAPOLEON procedure or immediately following statement 
10, the code for the LEGS, The preferred debugging strategy is the one 
that does minimal violence to the user 1 5 code, reflects the abstract 
plan, and fixes the greatest number of violations. 



4U7+1 Plausibi lity on the Basis or Side Ef fect s 

The first criterion for Judging the- success of a partial 

debugging strategy is an analysis of the side effects of the 

corrections. The debugging strategy with maximal beneficial Side 

effects is preferred. Beneficial side effects OCCIIT by eliminating 

additional rootled violations, satisfying planning expectations or 

eliminating violations of rational form. 

One might ask why an edit might have any beneficial side effects 
at all, Un't it more likely to have bad Side effects and cause 
other violations? The answer is that often. several violations 
art) caused by the seme error in the code. Then one debugging 
strategy will stand out from its brethren by filing this error 
and thereby simultaneously curing Several violations. 

On the other hand, sane times a correction causes additional 

no del violations. In this case, either the new violations can 

themselves be debugged or the debugging strategy must be abandoned. 

Assumption and protection commentary are used to help in understanding 

those bad side effects wherein one edit undoes the effect of snmn other 

debugging edit. If the bad aide effect cannot be eliminated, then the 

debugging strategy must be rejected. This is the case with a linear 

debugging or QOOQLY.EYES (.figure 4i.5), 

The eyes cannot be brought into the head by shrinking the interface 

without causing them to overlap the nose. Thus this debugging strategy 

eliminates one violation (OVERLAP EVE HEADJ only to introduce another 

(OVERLAP EYE W05EJ. The system is forced to Consider non-linear 

debugging and fix tbs parts themselves. 


4 - 7.2 Plausibility on ths Basis oJF Minimal Change 

Another plausibility criterion is that of minimal change to the 


user's coda. A debugging strategy that changes an input is preferred to 





GQOGLY EVES 

FIGURE 4.5 

one that adds statements; and a strategy that adds statements is in turn 
preferred to one that deletes them- The rationale is that a repairmen 
Should make nsinimal changes to a system. The goal Is to fix the program 
in harmony with the user's intent, not to redesign it, this caution is 
further- justified by the fact that the system does not fully know the 
progrynmcr 1 s intent or plan. Hence, it must he hesitant tn make major 
revisions to his program. 

4.7.3 Plausibility Oft the Basis Of Caveat Comments 

A third hails for choosing between alternative debugging 
strategies is advice from the annotator and plan-finder on likely 
errors. The annotator alerts the debugger to oddities in program 
Structure which may be the underlying causa of some semantic violation 
(section Z.4), The plan"finder fulfills the same purpose with rospett 
to Code that contradicts expectations arising from the typo Of plan. 

The mechanism of informing the debugger of the: possibly erroneous code 
is through "caveat" comments, The eomfients are noticed whan the 
debugger considers the associated code in the course of dchugging sorse 
medal violation. A repair edit is accorded extra plausibility by the 



debugger if thO correction eliminates the complaint that initiated the 
caveat. 

Caveats generated by the plan-finder are created by noting 
insertions which aro not transparent K interrupted-stops which depend on 
specific runtime environments and Linear plans in which main-steps Lise 
the same resource such as an assumption about a particular state 
variable. In an extended system* caveats would be generated by such 
oddities as iterative programs which fail to halt and shared free 
variables. As an example, recall that the arms in NAPOLEON represented 
a non-transparent Insert and that this information advised the debugger 
to edit Che correction into VEE rather than directly Into the NAPOLEON 
Stiper-procedure, 

Comments are used--rather than the Annotator or Plan-Finder 
immediately calling the Debugger to correct the violation—because a 
Violation of rational form is not a guarantee of a bog] the oddity may 
be harmless or even intended by the programmer. An example in which a 
-sequence of FORWARD instructions arises naturally is the following 
triangle program: 

TO TRI 

Id foRWJWD $d 
30 FORVAUD 50 
30 RIGHT 130 
40 FORWARD 100 
50 RIGHT |£C 
GO FORWARD 100 
END 

The first two FORWARD'S are surprising. However* if this TRI is being 
debugged in preparation for being converted to a triangular head with 
the remainder or the stlcK-man Inserted as stataoeot 15, then the 
apparent violation of rational form is explained. The Utility of 
comments is that If the code is not suspected of being in error by the 
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debugger, the cociaent has no Effect, It plays a role only If DEBUG 
finds a model violation that can possibly he corrected hy changing the 
Odd code, Odly then does the Comment enter ihte the analysis by 
supporting such adding plausibility to debugging strategies that 
eliminate Its complaint of non-transparent insert or sequential 
commands r 


d.7.^ Guessing the Culpable Int erface 

Even with the restriction to linear edits, fixing a predicate 
relating two main-steps may produce many possible edits. For example, 
making the head above the legs in NAPOLEON could be done by adding a 
rotation at any of several placES in thfi program preceding the execution 
of the TftltOftN sub-procedure. Consequently, the system initially 
considers edits to only two interfaces - - the interface immediately 
preceding the second main-stop 11,6. code lor the model part 
accomplished last] and the initial setup to the program- The immediate 
interface it preferred on the expectation that preceding interfaces have 
already been protected in the course Of debugging. The global Setup is 
considered he causa "Unexpected Hun tine Environment" is a conmon cause of 
■errors. The plausibility of these editing points is then analyzed by 
the critaria described in the preceding sections -- beneficial side 
effects, minimal change, and caveats as well as the protection criteria 
described in the preceding section. IT they are found implausible,, 
additional interfaces are Considered in order, proceeding backwards fron 
the second main'-step. 


4,0 $U fin ARY OF DEBUGGING CONCEPTS 


The debugger's knowledge divides into twci categories; general 
debugging technique end specific imperative knowledge of logic end 
geoinfitry. 

Debugging Technique 

1. Linear Attack -* First verify main-steps privately. Then analyze 
relations in terms of interfaces. Only if all else fails, modify 
main-steps to fix relations. 

E. Plausible Search -- Compare alternative debugging strategies using 
plausiblity criteria of minimal change tn the user's code and 
maximal beneficial side effects. 

3, Cuipciblo Interfaces -- Prefer either the initial interface or the 
interface immediately preceding the bugged module. This is based 
an the assumption that the temporal attack has already verified 
intermediate interfaces, 

4, Caveats -- Use caveat c aments generated by the Plan-Finder and 
Annotator to suggest the location of the repair. 

5, Intrinsic versus Extrinsic Errors -- Classify model violations as 
intrinsic or extrinsic on the basis of whether the error Is 
internal to the code being examined- Intrinsic errnrs have limited 
scope and can. be debugged privately, 

fi. Handling Multiple Bugs -- debug those violations of most-limited 
scope first; that is, debug properties before relations; then 
intrinsic predicates before extrinsic ones, and finally in temporal 
order. 

7^ Commentary - - Use commentary to express the purposej assumptions 
a.nri .scope (protection) of a correction and to notice COrt flicts 
between different corrections, 

know Ledge of Geometry and Logic 

l. Imperative Semantics of Predicates - En addition: to standard 

verification code, primitives have semantics that suggest what to 
do tp make the predicate come true. This consists of procedural 
Knowledge which examines code and generates edits to make a 
particular geometric predicate true. 

3. Rigid Body Theorem - This theorem is a precise statement of the 
effect OT the initial environment on a segment of code for Fixed- 
In struct ion Turtle Programs, namely that the carte produces a rigid 
body and that the initial environment affects only the orientation 
anct position. 
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3, Imperative Knowledge for logical Predicates - Procedures for makin 
conjunction, disjunction, natation, equality and set oemhorship 
true with minimal. effort. 


4.9 Classification of Bugs 

The following taxonomy of bugs suenariees the types of errors 
which the system corrects. 

Linear Main-Step Failure: 

Manifestation: Failure of main-step to accomplish model 

part in private,, i.e. whoa run independently. 

Fin; (Private Debugging) Repair in private, rejoin and 
satisfy any initial assunplions, 

IiXi (NOT (EQUITRI TRICORN) ) in NAPOLEON. 

Preparation Error: 

Manifestation r Violation of relation between model parts., 

Fix: (Linear Debugging) Find culpable interface, make 

edit suggested by the inpnrative semantics for the 
predicate, and protect assumptions and behavonr until 
the point at which the error vas manifest. 

Ex: See Unexpected Runtime Environment and Local 

Preparation Errors 

Unexpected Runtime Environment: (type of preparation failure) 
Manifestation: Violation due to false assumptions oT 

the entry state to program. (Program does succeed in 
certain environments)- 

Fix: Add an initial setup which converts the actual entry 
state to the desired entry state. 

Ex: (NOT (BELOW LF.CS ARMS)) In NAPOLEON, 

Local Preparation. Errort (type of preparation error) 
Manifestation: Violation intrinsic to the program., 
and not dependent on the initial environment, 

FiX: Modify state appropriate to the imperative semantics 
for the violated predicate. 

Ex; (NOT [VERTICAL TRUNK.) ) in TREE4, 

Non-Lineaf Main-Step Failure: 

flan ifestalion ; Main-step succeeds in private. 

Fix: See resource conflicts, insertion errors, 
and gl Dbal errors described below. 



Unconsidered Second-Order Constraint on Main-step: 

(type of mon-llncar nain*stop failure) 

Manifestation:; Violation of a property of model part 
not detector! in private, Manifested by analysis 
of a relation between the imam-step and seine 
other model part. 

Fix: Modify maid’-Step in ouch a way that Violation is 

corrected while the first-order description of propertie 
asserted in the model is still satisfied. Guidance is 
provided by the imperative semantics for the predicate, 
Examples of such transformations are dilation and 
reflec ticn. 

Ex: (MOT (INSIDE MOUTH HEAD)) In BIG.MOUTH, 


Resource Conflict; 


(type of non-linear main-step failure} 


(Mentioned for completeness] not handled by debugger.) 
Manifestation: Violation of property of part 

described in model which was not exhibited in private. 
Fix: Some assumption made when run privately is bein') 

violated in public. Such an assumption could he the 
availability of a given resource, e,g, a free varieb]». 
Ex; Attempt to correct both {VERTICAL BODV) and 

{HORIZONTAL {SIDE TOR)} in TREE* by modifying the 
initial interface statement 5 (section 4,6] 


Insertion Error: {type of non-linear main-step failure) 

.Manifestation] Main-step failure not indicated in private 
with the additional element that a caveat comment 
generated by the plan-finder informs the debugger 
that the code group for the main-step surrounds an 
insert which is not transparent- 
Fix; Make Insert state-transparent, 

Ex: (MOT (LINE BODY)] ih NAPOLEON, 

Global Error: 

Manifestation: Model part accomplished non-locally fails, 

Fix: Find relevant theorem which was the basis of expecting 
thfl global plan to succeed. Find assumptions made by 
theorem wh ich were not Justifled. Hake these assumption 
true. 

£x; [NOT {LINE (SIDE 1 TRICORN})] in NAPOLEON. 


5, CONCLUSIONS 

5.1 TOP-LEVEL DEBUGGING GUIDANCE 

The top- level organization of no del-driven debugging is to order 
the model violations and then proceed to fix them in turn. This 
technique makes the basic assumption that guidance in fixing the progran 
can be obtained by analysing the specific details wherein the picture 
failed to satisfy Its description. Alternatively, top-level guidance 
Cdn be obtained through: 

1. Structure-drivea debugging - Insight Into the form of programs, 
e.g. such structural considerations as recursive and iterative 
control patterns and global versus local variable scope, 

Z- evolution-driven debugging - the evolutionary or editing history 
of the uter's code. 

3. process-driven debugging - the abstract Torm or the process at 
the tijtte of the error [Sussima 1973J. 

A more complete debugging system would exhibit all of these forms of 

direction. 

5.2 GENERA LIN ABI LITY QF DEBUGGING TEC HNI QUES 

The mini-world of programs against which this analysis of 
debugging is tested is that Of fixed-instruction turtle procedures. 

These are, of course, a particularly simple form of program. Their 
simplicity allows the Imperative semantics Tor the geometric primitives 
to utilise the Rigid Body Theorem, justifying the sane state change to 
different interfaces to correct a given bug. 

The debugging techniques used to handle even these simple 
programs are by no Fieans exhaustive. Nevertheless r it is worth noting 
that many of the techniques utilized by the randal-driven debugger aro of 
broad application: an initially linear analysis, the need to order the 








attack on multiple bugs, competence to copo with alternative debugging 


stratcgies^theso arc useful regardless of the nature of the tup-level 
direction or the complexity of the program- 

The choice of plane geometry as the a email tic domain for ftVtftdFT 
was not accidental, fteonetry allows the use of a Cartesian annotator 


and. a powerful model language for specifying spatial relations,. Other 
domains may not be susceptible to a nvCRQFT-1 ike approach because of the 
lack of powerful ways in which to docunent the effects of the program 
and the lack of a good model language. However, it is worth noting two 
points: 


spatial medals are very important for programming in 
applications beyond graphics. [This is reflected in the way 
programmers refer to memory. Stacks and data structures in 
spatial ways.) 

and 2. program planning and debugging involve techniques of broad 
applicability but cannot be entirely dona in the absence of 
domain-dependent knowledge, 


5.3 EXTENSIONS 

The design ef NYCRQFT required an investigation of fundamental 
problem solving issues including description, simplification, linearity, 
planning, debugging and annotation, flYCRDFT, however, is only a first 
step in understanding these ideas. Further investigation of more 
complex programs, anti ef the semantics of different problem domains is 
necessary. It is also essential to analyse- additional planning concepts 
such as ordering, repetition and recursion as well as the corresponding; 
debugging techniques- Ultimately, such research will surely clarify the 
learning process ill both men arid machines by providing an understanding 
of how they correct their oku procedures. 


Goldstein 
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